Add Webm medium quality preset and fix MP4/Webm presets - #385

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (dbb7534) to head (9c7c2c4).

@@            Coverage Diff            @@
##              main      #385   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           42        42           
  Lines         2947      2952    +5     
  Branches       452       452           
=========================================
+ Hits          2947      2952    +5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

@benoit74

@pawank925 did you tested that against some real videos? We used to have some test videos but I don't find them anymore ...

@benoit74 Yes — and the videos are still in the repo, I think you're remembering the other set.

tests/files/video.mp4, video.mkv and video.webm (plus audio.mp3) are the fixture videos, added back in a5ae0421 (2020-05-20) and unchanged since. They're real footage, not generated patterns: 1920x800, 24 fps, 2.63 s / 63 frames. The set that is genuinely lost is the three videos from #79 (Khan Academy chalkboard, TED talk, news spot) that you mentioned in #271.

The two new @pytest.mark.slow cases in this PR do run on those fixtures (video.mp4 -> VideoWebmMedium, video.mkv -> VideoMp4High), and CI executes them via --runslow — all green on db8e16e. But those assertions only check codec and duration, which says nothing about whether the preset is actually sane. So I also ran the presets locally (static ffmpeg 9.0, arm64, VMAF against the fixture itself as reference; input = 1,259,106 B) and measured the output:

Three things worth noting from that:

• Medium lands between low and high on both size and VMAF, which is the intent.
• The CRF 20 -> 28 change is the fix the PR body claims: CRF 20 produced a file larger than its input on this clip, CRF 28 gives 58% of the input at VMAF 91.
• -row-mt 1 is a speed option, not a quality one: WebmLow goes 94,315 B -> 94,186 B with it, i.e. the same output within 0.1%. Matches @DasDunkel's "same size and quality file" in Add Webm medium quality + fix MP4 high quality presets #271. I still bumped the preset VERSION because the output bytes do change and scrapers key their caches on it — but happy to drop that if you'd rather not invalidate caches for a 0.1% difference.

The honest limitation: this is one 2.6-second clip of one kind of content, so it is nowhere near the "significantly tested on multiple kinds of videos" bar you set in #271. The parameters themselves come from @DasDunkel's 15-video YouTube set and the comparison script in #271, not from my own testing — my runs only confirm they behave as described, they don't re-validate them across content types.

If you want that before merge, I can re-run @DasDunkel's script over the 15 IDs (low/med/high, webm + mp4) and report the full per-video numbers. And if you'd like the repo to stop losing its test set, adding a couple of varied fixtures to tests/files/ — static-background lecture slides and something with fast motion — would let the slow tests assert size/quality rather than just codecs.